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(57) A method and system are provided for control- 
ling a computer, data, or media system in response to 
state changes in the computer system. At least one state 
table having a first dimension and a second dimension 
is created. At least one programming element is listed 
along the first dimension and a plurality of states of the 
computer system are listed along the second dimen- 
sion. At each intersection of the first dimension and the 
second dimension is a cell in which an operand is spec- 
ified for the programming element at each state. For 
each state change of the computer system, each pro- 
gramming element listed along the first dimension is ex- 
ecuted according to the operand listed for a current 
state. 




r 



900 



Enter Programming 
dement and Each 
Function Call Operand 
Needed in Each Cofcimn 
for Each State 



0 



Enter Programming 
Element and Each ValuB 
Operand Needed far 
Each Stats 



Enter General Function 
Call and Enter Each 
Segment of Function 
Code For Each State 



D 



Enter Argument for 
Execution with Called 
Function 



Go to Next Function 
Needed in State Table 
File and Next Row in 
State Table 



Fig. 9 



a 

UJ 



Printed by Jouve, 75001 PARIS (FR) 



BEST AVAILABLE COKY 



Description 



EP 1 380 944 A2 



f 



and 9 svS *S* "•«*>". Sod 

are incorporated by reference Wh ' Ch 

K Ma ? y P ° SitiVe """V"*- have resulted 
from the continual improvements in the pricJiS? 

=S=~==== 

of the program. At the same time, the STB has to un 



dertake many functions which mav not c a =„ 
the user. Forexamole th- «™ u V a PParent to 
•channePchoXSv^^- ha8tocoo « , '"«e which 

ShepS^ 

therefore. Jw^STi*" aff ° rdab,e and ' 
» withintheSTBisven/Zr; the ,. 00mpUter hardwara 
AtyptelCTBboSS^ ^^^standards. 

ornoprogramr^^ 
-dio J^^JSSFV* Vide ° 3nd 

user nteraction with a «r« ° to a " ow 

and similar information to allow an meresTed v name ' 
Purchase an item indirectly there a™ SWert0 

„ j '« y purchase * opportunities 

55 DO-WHll P in«u«i 'F-THEN-ELSE or 

. WM,LE ,0 9'cal constructions, are useri to toot f 



2 



3 



EP 1 380 944 A2 



4 



ations keyed thereby can then be combined into more 
complex behavior to create the appearance of a sophis- 
ticated application. 

[0009] These first and second challenges may, how- 
ever, conflict with each other. Capturing desired appli- 
cation behavior in a series of testing statements can re- 
quire extensive code. Further, in the STB environment, 
both storing and securing the bandwidth to obtain nec- 
essary conditional coding sections present problems. 
[001 0] In order to try to effectuate desired conditional 
programming behavior in a compact data size, some 
program logic can be converted into equivalent data 
content. The data content, with the desired behavioral 
aspects of the application embedded therein, can inter- 
act with the control logic to execute the desired behavior 
without downloading all new application code for each 
desired set of functions. 

[0011] One example of how this is done is a data-driv- 
en control mechanism such as that described by Wa- 
tanabe et al. in U.S. Patent No. 6,223,347, "DATA DIS- 
PLAY CONTROL APPARATUS" ("Watanabe"). Watan- 
abe discloses a system which uses pre-encoded data 
to specify changing the appearance of an application ac- 
cording to pre-determined behaviors which are institut- 
ed by the receipt of user actions, or by the passage of 
time. For each of a set of display screens, modifications 
of properties of .elements otthe screen.can.bejiiade.by_ 
invoking a "handler. 0 A handler is a small byte code se- 
quence which accomplishes some change in the system 
properties, such as making a button visible or invisible, 
or displaying an alternative screen. FIGURE 1, which 
represents FIGURE 6 from Watanabe, shows a pre-en- 
coded data element 100 as disclosed by Watanabe for 
controlling the appearance of a single display screen. 
[0012] Viewed practically, Watanabe's data element 
100 is a code fragment which dictates the response of 
the application in response to changing conditions. The 
data element 100 manifests an IF-THEN construct 
keyed by whether a user selects a VIDEO button 1 06 or 
a STEREO button 110. Moreover, the data element only 
encapsulates one aspect of the behavior for one single, 
conditional choice. To create a complex behavioral re- 
sponse to the user input, a series of stacked data ele- 
ments like data element 100 would have to be created. 
[0013] In addition, the system of Watanabe has a 
drawback which is shared by other similar systems such 
as web browsers. The Watanabe solution employs dis- 
crete code fragments which are executed in response 
to particular behavior, in just the same way that a web 
page is encoded to activate a link when the user clicks 
on a button or block to which the link is associated. As 
such, just as in a web browser the navigation available 
to the user is limited to the pre-defined URL links em- 
bedded in the source code for the page, under Watan- 
abe the programming logic is fixed at design time to han- 
dlers pre-coded in the application. Also like a web 
browser, in which the transition to a new page represent- 
ed by the link is automatic in response to the link being 



w 



15 



20 



25 



30 



35 



40 



45 



50 



chosen, under Watanabe's system the behavior is re- 
sponsive to the last conditional branch taken by the sys- 
tem in response to a user selection. Watanabe cannot 
take account of previous states from which the user se- 
lection was made or based on a combination of varia- 
bles. The user's experience is based solely on the ap- 
plication's response to the last individual selection made 
by the user. 

[0014] One alternative to the simple selection/pre-en- 
coded direct response system of Watanabe is to create 
an executable application which implements behavior 
based on conditional testing of multiple application var- 
iables or inputs. However, an inefficiency inherent in 
constructing application behavior from conditional pro- 
gram logic is that each potential alternative condition 
must continually be tested for and operated upon. Some 
reuse of code is always possible, but generally the code 
has to be modified to manifest all the variables and the 
consequences of their values to handle each new spe- 
cial case of behavior. In other words, with reference to 
the example from Watanabe, the same byte code spec- 
ified in the Bytecode_Part 150 would have to be incor- 
porated into the conditional program logic, but would be 
surrounded by code to test for which subset of byte code 
should be executed. This conditional code must be ex- 
ecuted before the 'operational' effect can be realized 

__from-the-core-byte.code,-which-leads-to-inefficiency: 

[0015] Adding or updating code also presents con- 
cerns from the standpoint of program storage, loading 
time, and data communications bandwidth. FIGURE 2A 
shows a computer system 200 and a typical application 
202 residing within the system 200. The system 200 
presents a hardware layer 204 which is controlled by a 
low-level hardware operating system 206, such as the 
Basic Input/Output System (BIOS) residing on a typical 
personal computer. An operating system or middleware 
208 typically runs above the hardware operating system 
206. Ultimately, the application 202 then resides on top 
of the operating system. If the application 202 has to be 
swapped out, updated, or otherwise changed, entire 
modules of code, or perhaps the entire application are 
changed. As shown in FIGURE 2B, loading a new, dif- 
ferent, revised, or updated application 202 would con- 
sume appreciable bandwidth of a data path 250. More- 
over, if the pathway is a relatively slow network line rath- 
er than a relatively fast local bus, the time and bandwidth 
required to communicate the application would be ap- 
preciable for one such transmission. The aggregate 
bandwidth consumed for a number of changes or up- 
dates can becomes a tremendous bandwidth concern. 
[0016] Thus, there is an unmet need in the art for con- 
trolling appearance and execution of computer applica- 
tions without having to create, load, and store code in- 
struction segments to control desired computer behav- 
ior in response to changing variables and conditions in 
which the application operates. 
[0017] Embodiments of the present invention provide 
a method, a computer readable medium, a data system 
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for controlling operation of a computer system oranin 
teractivemedlacontrol system for efficient control of the 
oper at , 0 n of a computer, data, or media control system 
Desired behaviors in response to changes in state of a 
system us.ng the present invention are coded in data 
form, and the data is processed in response to state 
changes. Accordingly, the present invention advanta- 

2w "I 0 * 8 f ° r aPP ' iCati0n b8haviors t0 be «>ded 
wrthout wntmg new code. Moreover, behaviorial func- 
tions of the system can be controlled or changed by 
^l 9l " gthe T .^ tawithout °"angingorloading a Entire 

2 I s ^ SUitab ' y ,akes the fom ° f * state 
teble which governs the operation of programming ele- 
ments, such as function calls orvalues beingset. in re- 
sponse to state changes wrthout having to create a^d 

on?*?" m ° nal C ° de f ° r m ° nit0rin 9 evef y behavior. 

0018 More specifically, embodiments of the present 
invention provide a method and system for contro ling 
computer system operation in response to statechang 
es in the computer system. At least one state table is 

I*"* *? ^ taWe has a f irst tension a7 d 'J 
second dimension. At least one programming element 

isstedalongmeflrstdimensionanda P .uralit?of states 
of the computer system are listed along the second di- 
mension. At each intersection of the first dimension and 
the second dimension is a cell in which an operand is 

For each stato nh Q „r,« *u toUlie - 
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For each state change of the computer system, each 
programming element listed along the first dimension is 
executed according to the operand listed for a.current 
stats. 

[0019] In accordance with further aspects of the in- 
vention non-null operands are pushedonto a stackfrom 
which they are retneved for processing, m one embod- 

hfi u K n ° n " nU " ° PerandS suttablv are P us "ed onto 
the stack by an execution model, and retrieved and 
processed by a byte-code interpreter. The programming 

Son ^ 7 reSem fUncti0n ca,,s ' for the 
function ,s speeded as an operand, automatic function 
calls, or value setting functions to set a value for a pro- 
gram variable. The programming element also can be a 
code segment of its own, as the state table can be of 

SZSZ T length ' Further ' the sta,e tebte can be 

subdivided into a state table structure, specifying the 
programming elements, and a state table file, specifying 

state table file can be changed and loaded separately 

Formsoftransitionsbehveenstatesforprogrammingel- 
ements can be specified with the operands, such as 
trans. , on types, final states, ortransition durations ora 
default transition can be used. 
[0020] The preferred and alternative embodiments of 
trie present invention are described in detail below bv 
way of example only, with reference to the following 
drawings, in which:- 9 
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35 



40 



FIGURE 2A is an operational hierarchy map of a 

R^ P R C S « yStem USin9 3 pri0r art a PP |ica «°n; 
RGURE2B,sagraphicaldepictionofadata stream 
using a pnor art application in which application 

code h as to be loaded in response to opTrafiona 

run-time changes; 

Snr 21? 18 9 S,a,e 196,6 aCCOrdin 9 t0 an embodi- 
ment of the present invention- 

FIGURES 4A-4F are screens from an interactive 
computerprogram displayedto a userusingan em- 
bodiment of the present invention- 

o F o^l E n 5 mk Sta,e tat " e COntr0, ' in 9 the ru "'«™ 

DlavSro t h imeraCtiVe C ° mpUter P"*™" dis- 
played to the user in FIGURES 4A-4F- 

FIGURE 6 is a structural map of a graphical user 
interface button into which new image data can be 

ZTi rUn " tlme aCCOrdin 9 t0 a " Mo- 

ment of the present invention- 
s' 7 r, 3 StrUCtUral map of a state table and 
state table file according to an embodiment of the 
present invention; 

FIGURE 8A is operational hierarchy map of a com- 
puter system using an application making use of a 
state table according to an embodiment of the 
present invention; 

^ E8B ! a i raphiCa,dep,Ctionofadate stream 



Z 21 T emb0dimen « of *e present invention 
changes? reSP ° nS8 t0 ° Pera,, '° nal run - time 

If 3 f ' 0WChaft ° f the ste P s used to create 
a state table according to an embodiment of the 
present invention; 

FIGURE 10 is a flowchart of the steps used in exe- 
cuting a state table according to an embodiment of 
the present invention; 

FIGURE 1 1 is a block diagram of a system using an 
embodiment of the present invention; and 
FIGU RE 1 Z is a block diagram of a data processing/ 
med,a control system using an embodiment of the 
present invention. 
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FIGURE 1 is a prior art navigation data construction 
used to drive a program based on user input; 



f mJL * m>ntS ° f the Present inventi °" P^vide 
on2 8 ndsVStemfor strolling computer system 
operation m response to state changes in the computed 
system. At least one state table is created, and the state 

St on" 3 ^ dimenSi ° n and 3 "«* 

least one programming element is listed along the first 

t e r^^ d ? P,Ura,i,y0,Sta,eSOftheMm p'tersys- 
tem are listed along the second dimension. At each In- 
tersection of the first dimension and the second dTmen- 
sion is a cel. in which an operand is speeffied ZxL 
programming element at each state. For each state 

1Z , ? C ° mPUter SyStSm ' each P-9ramming ON 
ement listed along the first dimension is executed ac- 
cording to the operand listed for a current state 

J?. 3 Sh ° WS 3 S,a,e ™ Wording 

to an embodiment of the present invention. The state 
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table 300 has five rows 302 and n+2 columns 304. The 
first column 306 is a list of operations or programming 
elements 308. As a result, it will be appreciated that any 
number of the rows 302 may be used as desired for a 
particular application as determined by the number of 5 
operations or programming elements 308 listed in the 
first column 306. The remaining columns 310 corre- 
spond with each of n+1 states 312 of operation that are 
contemplated for the behavior of the system using the 
state table (not shown). It will be appreciated that there w 
are n+1 states because the first state is State 0 314. 
Thus, if the last state is State n 31 8, there are a total of 
n+1 states. There are n+2 columns because there are 
n+1 states and the additional first column for the list of 
programming elements. 15 
[0023] At intersections of each of the rows 302 and 
each of the columns 308 after the first column 306 are 
cells 320 containing operands 322. In each cell 322 is 
listed an operand for the programming element speci- 
fied in the first column 306 for that row. Thus, there are 20 
n+1 operands 322 specified for each programming ele- 
ment 308 listed in the first column 306 of each row 302, 
one for each contemplated state, State 0 314 through 
State n 318. The operands 322 specify an argument 
needed for the programming element at each of the 25 

states 312. - ----- - 

_IQ024] Operation of a system can begin ata-noa*state 



(not shown) or with State 0 314. Upon initiating State 0 
314 and upon progressing to each state 312, the pro- 
gramming element 308 in each row is executed accord- 30 
ing to the operand 322 specified in the cell 320 for that . 
programming element 308 at that state 312. In the em- 
bodiment shown in FIGURE 3, the programming ele- 
ments each are executed sequentially, from top to bot- 
tom, although another order could be selected as de- 35 
sired for a particular application. Depending upon the 
system being controlled by the state table 300, the 
states 312 can be stepped through sequentially from 
State 0 314 through State n 318, or can be randomly 
accessed. Initiation of state changes suitably results 40 
from the passage of time, in response to system or user 
initiated directives, or based on other changing condi- 
tions. The state table 300 thus can be adapted to a va- 
riety of applications and contexts. 

[0025] Given by way of non-limiting example, the first 45 
programming element 308 listed in the first row 330 of 
the first column 306 is "Store in Button 1. Visible" 324. 
For the sake of this non-limiting example, a button rep- 
resents a displayed icon, having a particular position, 
size, and appearance, which a user of the system, such so 
as a computer or an interactive media control system, 
can select to direct the system according to his or her 
desires. The programming element 308 suitably repre- 
sents an automatic function call, one of a number of suit- 
able programming element types. The "Store in 55 
Button 1 .Visible" programming element accepts two op- 
erands 322: "True" 326, as specified at State 0 314 and 
"False" 328, as specified at State 1 316. As will be ap- 



preciated, while the operands True" 326 and "False" 
328 are spelled out, they could be represented by nu- 
merical codes, one-byte symbols, and other forms. In 
response to the True operand 326 and the False oper- 
and 328, the programming element 324 causes Button 
1 to become visible at State 0 314, but become invisible 
at State 1 316, respectively. A transition from State 0 
314 to State 1 316 may be indicated by expiration of a 
set time interval, receipt of a state change signal by the 
system running the state table, a user initiating a state 
change by pressing a button or otherwise issuing a com- 
mand, or in other ways. The data table manifested in the 
state table 300 thus dictates program behavior in re- 
sponse to state changes. 

[0026] The state table 300, however, need not exe- 
cute only one row and thus one programming element 
at a time. The state table 300 suitably causes to be ex- 
ecuted each programming element listed for each oper- 
and specified for each state. By way of this non-limiting 
example, for this state table 300 with five rows 302 of 
programming elements 308, up to five programming el- 
ements are executed for each state change, as will be 
further described. At State 0 31 4, the first programming 
element "Store in Buttonl .Visible" 324 first is executed 
with the operand "True" 326. Second, the programming 
" element "Integer Value" 3307a valueTetting program"- " 
ming e l emen t , s o ts thec al ue to 43. Th i rd, the prog ra m - — 
ming element "Store in Buttonl. Left 1 * 334, another au- 
tomatic function call, sets the left-hand position of But- 
ton 1 to 100. Fourth, the "Call Math Func() with argu- 
ment" programming element 338 specifies that function 
Math() is executed with the argument 12. Finally, the 
"Call given function" programming element 340 initiates 
the function specified by data element 336 at State 0 
314, namely "Fund 2," which will then be executed. It 
will be noted that this programming element is a function 
call that is not an automatic function call as are program- 
ming elements 324 and 334. Instead of the program- 
ming element 308 specifying the function to be execut- 
ed, the function to be executed is specified by the oper- 
and 336. Using a non-automatic function call advanta- 
geously allows for different functions to be executed by 
the state table for different applications by changing only 
operands in the state table, without changing the pro- 
gramming elements. As will be described further below, 
this allows the state table structure to be reused be- 
tween different applications while changing only the 
state table data. 

[0027] Upon the transition to the next state that is 
State 1 316, the programming elements 308 are execut- 
ed according to the operand specified for each program- 
ming element at this state, with one exception noted in 
the example. First, "Store in Buttonl. Visible" 324 is ex- 
ecuted with the operand "False" 328, thereby making 
the button invisible. Second, the programming element 
"Integer Value" 330 sets the value to 26. This value can 
be read by program code. Third, the programming ele- 
ment "Store in Buttonl .Left" 334, this time, is not exe- 
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cuted. This is because there is a null operand 
NO_CHANGE" specified forthe programming element 
334 for the current state. When a null operand is spec- 
ified for a programming element, the programming ele- 
ment is skipped. Therefore, a vast number of program- s 
mmg elements could be specified, even if some of them 
are seldom used, and the programming elements are 
merely skipped until transitioning to a state where a non- 
null operand is specified. Fourth, the "Call Func() with 
argument" programming element 338 calls the function w 
Func() with argument 14. Finally, the "Call given func- 
tion" programming element 340 initiates the function 
Stetf 1 3 P i? ified Pr ° 9rammin 9 element 33 8 at 
[0028] It will be appreciated that, as the programming is 
elements 308 are executed (or not executed, if a null 
operand is associated with the programming elements 
308 for a current state change), no conditions need to 
be tested, let alone coded. The desired behaviors are 
encapsulated in the state table 300 to manifest and con- 20 
trol the execution of the system based on the operands 
coded for each of the programming elements 
[0029] It also will be appreciated that transitions be- 
tween the states can be controlled in a number of ways 
known to those ordinarily skilled in the art. For example 2s 
arguments c ould be supplied with the operands speci- 
fying whethei tt re tra isttlon Is lobtt n lade abrup t ly, faded 

in W/inorlfrnm nnn nl^» _.n 



in, wiped from oneside orthe other, or another way. Sim- 
ilarly, the speed of transitions or a duration during which 
the state change remains in effect could be specified by 30 
an argument. Default transition types and durations 
could be supplied if such arguments are not specified 
[0030] For clarity, an extended non-limiting example 
of the operation of such a state table-driven system is 
provided in FIGU RES 4A-4F and 5, which depict an ex- 35 
ample of a cooking show overlaid with information and 
interaction opportunities for users. In FIGURE 4A ahost 
400 appears at a countertop 402, as such programs typ- 
ically begin. In FIGURE 4B, the visual component of the 
show is overlaid by a computer or media control pro- 40 
gram presenting a recipe 404 for a dish being prepared 
listing the ingredients that will be used to prepare the 
dish. In FIGURE 4C, the host 400 is working with a first 
of the ingredients in a bowl 408, and that first 41 0 ingre- 
dient is highlighted on the recipe 404 displayed to clarify 45 
what the host is doing at this point in the program In a 
next frame shown at FIGURE 4D, the recipe is removed 
to remove objects from the display for clarity or for an- 
other reason, while a special symbol 412 is appended 
over the bowl containing the ingredient at issue. The in- so 
sertion of this special symbol 412 gives the user a 
chance to purchase the bowl 408 interactively. In FIG- 
URE 4E, the special symbol 412 has been removed the 
recipe 404 reappears, a second ingredient in a container 
414 is being used, and the second ingredient in the rec- 55 
ipe 41 6 is highlighted. This time, again as a choice per- 
haps for visual clarity as the host 400 works with a sec- 
ond ingredient 41 4 on a right side of the screen, the rec- 



iPe c^.! S m ° Ved t0 the left side of the screi >n. Finally, 
in FIGURE 4F, all the graphical objects overlaying the 
program have been removed. 
[0031] An embodiment of the present invention allows 
this graphical information to be transmitted to a device 
displaying the program. The changes in information can 
be keyed to triggers in the program, and interactive op- 
portunities similarly can be created. It will be appreciat- 
ed that these advantages can be accomplished by mod- 
ifying a state table, such as the state table 500 shown 
in FIGURE 5, without having to use conventional video 
editing and/or create or edit instruction code. 
[0032] Referring now to FIGURE 5, a state table 500 
lists programming elements 502 in a first column 504 at 
left, and operands 506 relating to each of the program- 
ming elements 502 for each of the succeeding states 
508 are inserted in cells 51 0 at intersections of program- 
ming element rows and state columns. It will be appre- 
ciated that the operands 506 inserted in the state table 
500 assume that execution of a system processing the 
program controlled by the state table commenced oper- 
ation before execution of the state table began As is 

S' n ^ h ^ 0nCUrrent ^ filedpatenta PP |icatione n- 
titled METHOD AND SYSTEM FOR FLEXIBLE 

TIME-BASED CONTROL OF APPLICATION APPEAR 

ANC j E AND .. BEHAV '° R;bearin g aao ™ y docket 

..»«i Uer in.wu/ U and previously incorporated by refer- 

ence, depending on how the state changes are triggered 
can affect the nature of the operands used 
[0033] At State 0 520, the programming elements 502 
for position of a series of buttons are established to 
present graphics shown in FIGURES 4B-4E It will be 
appreciated that objects used to present a recipe which 
is not interactive in this example, are suitably the same 

asabuttonobjectthatwillbeusedtorepresentaspecial 
symbol. A difference is that the special symbol is set as 
will be explained, to respond to user input, while the rec- 
ipe is not. Having only one object to present such graph- 
ical materials, interactive or not, advantageously simpli- 
fies code to execute the state table, as will be further 
explained below. Operands in the column for State 0520 
establish initial left and top positions of the recipe but- 
tons, buttons 1, 2, and 3, 410, 416, and 418 (FIGURE 
4E), respectively, as well as the special symbol 412 but- 
ton 4. Subsequent programming elements also set all 
the buttons to visible=False at State 0 520, because the 
buttons are not displayed at an initial state, as depicted 
-n FIGURE 4A. The colors for text and background are 
set, and a function call which will later be used for the 
special symbol/purchase opportunity is set to a 
NO.CHANGE null-operand. In this case 580 the 
NO_CHANGE operand signals that no function call is to 
be made. The parameters are now set for the beginning 
of the program. 

[0034] AtState 1 530, it will be appreciated that all but 
three of the operands specified forthe programming el- 
ements are NO.CHANGE null operands. As a result 
advantageously these programming elements can be 
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skipped without processing or conditional programming, 
and thus dealt with very efficiently. More accurately, 
these programming elements with null operands are not 
dealt with at all. Accordingly, while great flexibility for ad- 
justing the parameters controlled by these programming 
values exists in the state table 500, the application need 
not process them at each step. Therefore, there is great 
flexibility without continual complexity. 
[0035] On the other hand, at State 1 530, the values 
for the "Store in Buttonl .Visible," "Store in Button2.Vis- 
ible," and "Store in Buttonl .Visible," which represent the 
recipe are changed from "False" to True," thereby caus- 
ing the recipe 404 (FIGURE 4B) to be displayed at State 
1 530. Again, as previousfy mentioned, the state change 
from State 0 520 to State 1 530 could be brought about 
as desired, such as by a coded signal, expiration of a 
set time interval, or another form of trigger. 
[0036] At State 2 540, once again most of the oper- 
ands for the programming elements are set to 
NO_CHANGE as the display changes from FIGURE 4B 
to FIGURE 4C. It will be appreciated that the only 
change between FIGURES 4B and 4C is that the first 
ingredient 410 (FIGURE 4C) in the recipe 404 is high- 
lighted by placing the text in reverse-video with regard 
to the_ background. This is accompiished once more 
through the button object by reversing the operands for 
the "Buttonl .Text'' and "Buttonl .Color" programming el- 
ements at State 2 540. Again, without conditional pro- 
gramming or additional coding, most of the program- 
ming elements advantageously can be skipped while 
the desired behavior is manifested by changing the data 
associated with the programming elements of interest 
for the state at issue. 

[0037] At State 3 550, once more most of the oper- 
ands are NO_CHANGE. The salient changes in the dis- 
played image of FIGURE 4D are that the recipe 404 dis- 
appears and the special symbol 412 signifying the pur- 
chase opportunity appears, triggering the interactive op- 
portunity for the user. This is all accomplished by chang- 
ing only five operands. The first four operands change 
the visibility for each of the four buttons. Specifically, for 
the visibility programming elements for buttons 1 
through 3 the operand is changed to "False," and for the 
visibility programming element for button 4 the operand 
is changed to "True." Finally, the "Call given function" 
programming element 580, a function call programming 
element, is changed from NO_CHANGE to "Func4," 
which is a pre-coded function call which will initiate the 
purchase opportunity. 

[0038] With regard to the "Call given function" pro- 
gramming element, it will be appreciated that instead of 
a pre-coded function the actual function code could be 
inserted here so that such features need not be pre-cod- 
ed. The cells of the state table can be variable in length, 
including even programming segments that original pro- 
grammers wanted to leave open or did not foresee. 
[0039] At State 4 560, more things change on the dis- 
play than at any other time, thus more programming el- 



ements have non-null operands than for any other state 
since the initial parameters were set at State 0 520. First, 
to move the recipe 404 (FIGURE 4E) from the right-hand 
side of the screen to the left-hand side of the screen, 
5 the left position of the three recipe buttons is set to a 
new value. Because the vertical position of the buttons 
is not changed, the top attribute is still set to 
NO_CHANGE. Because the recipe 404 now reappears 
at State 4, the three recipe buttons' visibility attribute is 
io reset to 'True." At the same time, because the interac- 
tive shopping opportunity ends, the special symbol but- 
ton 412 disappears with its visibility attribute reset to 
False. Also, because now, as shown in FIGURE 4E, the 
recipe button 2 41 6 is highlighted while the recipe button 
15 i 410 is returned to normal video, the text and button 
color operands are changed. It will be appreciated that 
this step could have taken place at State 3 550 when 
the buttons were invisible, if desired. Finally, the "Call 
given function" programming element is reset to 
20 NO-CHANGE, foreclosing the user interaction opportu- 
nity. 

[0040] ' Finally, at State 5 570, the only change to be 
manifested is that the recipe 404 once again disappears 
as shown in FIGURE 4F. Accordingly, the visibility at- 
. tribute. pp.erands.fpr. each. of Ithejhree. recipe, buttons.. 
410, 416, and 418 is set to False. Because nothing else 
" cnanges, once again the remaining operands are all 
NO_CHANGE operands which can be skipped by the 
system. 

30 [0041] FIGURES 6 and 7 further illustrate the efficien- 
cy of a table-driven system with reference to the button 
manipulated by the state table 300 of FIGURE 3. FIG- 
URE 6 shows attributes of a button 600 which, for sake 
of example, suitably has five properties: left position 
35 602, top position 604, size 606, visibility (yes or no) 608, 
and image content 610. Presumably, every button of 
every application which will be created has those same 
five declarative properties. As previously described in 
connection with FIGURE 3, variables concerning the po- 
40 sition or appearance of a button can be dictated by pro- 
gramming element 324 for "Store in Buttonl. Left." Ad- 
vantageously, nothing new needs to be coded into ap- 
plication code executing the table to position or format 
a button. Instead, according to the invention only new 
45 data such as values for left position 620, top position 
622, size 624, visibility 626, and image content dictated 
by an image file 628 need be provided. This data is pro- 
vided as operands in the data table, as previously de- 
scribed. Numeric values for left position, 620, top posi- 
50 tion 622, size 624, and visibility 626 can be entered into 
state table fields. In addition, new image appearances 
in the form of an image file 628, such as, without limita- 
tion, icons, can be entered a state table field as well. 
State table fields can have variable size to accommo- 
55 date such blocks of graphical data. 

[0042] FIGURE 7 further shows how efficient data 
communications result from the state table structure. 
Referring back to FIGURE 3, in the state table 300 the 
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first column 306 lists the programming elements 308, 
and the remaining columns 310 specify operands for 
those functions at successive states 312. For example, 
the application might be a game show with which a user 
can play along. The underlying game show is a telecast 
of video and audio data. Overlaying that telecast are 
suitably buttons which the user can selectto choose an- 
swers, and a computer or media control system can 
trackthe user's score. For a game show repeated nightly 
or weekly, all the programming elements might be the 
same in terms of buttons being displayed, answers be- 
ing scored, etc., from show to show, but the precise val- 
ues and appearances of those buttons might change. 
Similarly, a game show with multiple rounds may use 
the same programming elements for each round, but dif- 
ferent operands and a different number of states are 
needed for different rounds. To specify the user's inter- 
action with the game, including the answers displayed, 
which answers are correct, how many questions are 
presented (and therefore states), and other information, 
behavior of the application can be recast by changing 
only the operands in the state table. 
[0043] Therefore, because the programming ele- 
ments do not change, but only the operands to control 
the same might be encoded, changing the application 
advantage ously does not require the creation and/or 
transmission of an entirety new slam table. I nstead, ac 
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cording to the invention the programming elements 308 
(FIGURE 3) listed in the first column 306 may remain 
the same, while only the operands in succeeding col- 
umns 310 are changed. Thus, as shown in FIGURE 7, 
a state table 700 can have a separate state table struc- 
ture 71 0 which includes the programming elements, and 
a separate state table file 720, which contains operands 
for tailoring the function of the application. Dividing the 
state table 700 into different components yields smaller 
blocks of data to be transmitted at one time. Moreover, 
a reusable state table structure 710, which could be re- 
used from week-to-week, day-to-day, or at least round- 
to-round would not have to be retransmitted each time. 
Instead, only a new data table file 720 would have to be 
retransmitted, thereby saving data transmission band- 
width. 

[0044] FIGURES 8A and 8B show benefits of a state- 
table driven system 800 in contrast to those of a con- 
ventional system 200 depicted in FIGURES 2A and 2B. 
Some elements shown in FIGURES 8A and 8B are the 
same as those shown in FIGURES 2A and 2B; these 
elements bear the same reference numerals, and a de- 
scription of the operation of these common elements will 
not be repeated. 

[0045] In the state-table driven system 800 shown in 
FIGURE 8A, the application 801 includes two parts. 
First, a general application code module 802 resides 
above the operating system/middleware 208. The gen- 
eral application code module 802 includes support for 
processing functions that may be initiated by program- 
ming elements in the state table 804, as well the func- 
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tions referenced by the programming elements and op- 
erands in the state table. This is a reusable module 
whose functionality will actually be driven by data en- 
coded in the state table 804, as previously described in 
connection with FIGURE 4. The general application 
code module is responsible for executing the behaviors 
encoded in the state table 804. Second, the state table 
804, a data construct, directs operation of the general 
application code 802, creating a data-driven system. 
[0046] As will be appreciated from FIGURE 8A the 
state table 804 is not as large as the general application 
code module 802. Consequently, to modify the applica- 
tion run by the general application code module 802 and 
the state table 804, instead of modifying the entire ap- 
plication 202 (FIGURE 2A) as required by conventional 
systems, only the state table 804 has to be modified 
Moreover, because the general application code mod- 
ule 804 provides support for processing a state table 
804 and executing general functions that may be initiat- 
ed by a state table 804, entire new applications can be 
created by creating a new state table 804 without having 
to wnte or debug new code, or load or otherwise com- 
municate new code to the system 800 running the ap- 
plication. Moreover, as previously described in connec- 
tion with FIGURE 7, application behavior can be 
changed merely by loading or transmitting a new state 
table fffg fnut gffirom) w it hout sending an entire new — 
state table, further reducing bandwidth requirements 
[0047] Bandwidth benefits of using the state table 
driven system 800 can be seen by examining the con- 
trast between FIGURES 2B and 8B. FIGURE 2B shows 
a conventional system as previously described in which 
the loading of a new, revised, or updated application re- 
quires the bandwidth and the loading time to load an 
• entirely new application. By contrast, FIGURE 8B shows 
that, in a state table driven system 800 (FIGURE 8A), 
revised, updated or entirely new applications can be 
made available by communicating only a new state table 
804. Assuming equal bandwidth across a data bus or a 
network communications link, communicating new state 
tables 804 requires far less bandwidth to change current 
applications or distribute new applications. 
[0048] FIGURES 9 and 10 depict in flowchart form 
methods of preparing and executing state tables. FIG- 
URE 9, specifically, depicts a method 900 for creating a 
state table. Beginning with a first row of the state table 
at a block 902, the method 900 iteratively determines 
what programming element is to be used. At a decision 
block 904, it is determined if the programming element 
is a function call. If so, for each state, the operand for 
the function call, whether an automatic function call or 
an ordinary function call, is provided at a block 906 Al- 
ternatively, if it is determined that a value setting pro- 
gramming element is invoked at a decision block 908, 
at a block 9 1 0 each state column is filled in with the value 
appropriate to the value setting programming element 
at each state. As a further alternative, if it is determined 
that a non-precoded function code segment is entailed 
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at a decision block 912, the function code segment for 
each state is provided in the appropriate column at a 
block 914. As a still further alternative, it is determined 
at a decision block 913 that a function call with argument 
is needed, at a block 915 the function is entered as the 5 
programming element and the arguments needed are 
entered in the appropriate state table column. If it is de- 
termined at a decision block 91 6 that not all of the de- 
sired functions have been captured in the state table, 
the next function is encapsulated moving to the next row io 
in the table at a block 91 8. Alternatively, once it is de- 
termined at the block 916 that all the behaviors have 
been encapsulated in the table, the table is complete 
and the method ends at a block 920. 
[0049] FIGURE 1 0 depicts a method 1 000 for execu- '5 
tion of a state table. If it is determined at a decision block 
1002 that a state change has occurred, at a decision 
block 1004 it is determined if the programming element 
is a function call and, if so, at a block 1 006 the operand 
designating the function call is pushed onto an execu- 20 
tion stack, and the function is executed appropriately. 
Alternatively, if the programming element is determined 
at a decision block 1008 to be a value setting program- 
ming element, the value is set to the value supplied in 
the current state column at a blqckjl 01 OL Also alterna- 25 
tively, if it is determined at a decision block 1 01 2 that the 

.... curren t e ntiy in thastate table column i s a function code, 

that code is executed at a block 1 014. As a still further 
alternative, if it is determined at a decision block 1013 
that a function call with argument has been made, at a 30 
block 1015 the function is executed with the argument 
listed in the current state table column. If it is determined 
at a decision block 1016 that not all the rows of the state 
table for the current state have been executed, at a block 
1 01 8 the system goes to the next row of the state table 35 
in the current state column and executes that program- 
ming element at a block 1 01 8. On the other hand, once 
it is determined at the decision block 1016 that all the 
rows for the current state have been executed, the sys- 
tem waits for the next state change at the block 1 002. It *o 
will be appreciated that if a null operand is encountered, 
that operand does not trigger any of the operations at 
blocks 1006, 1010, or 1014, and the method simply 
passes to the next row in the state table or, if the null 
operand is the last row, the system waits for the next *s 
state change at a decision block 1 002. 
[0050] FIGURE 11 shows a block diagram of a system 
1 1 00 for executing an application using a state tabie ac- 
cording to an embodiment of the present invention. The 
system 1 1 00 is keyed by a state change driver 1 1 02. As so 
previously described, the state change driver can be a 
timer, a signal receiver for acting on a manual signal, or 
another device that initiates a transition to a next state. 
More specifically, the state change driver 1102 keys an 
execution model 1104 which engages the state table 55 
1 1 06. The execution model 1 1 04, in accordance with the 
method described in connection with FIGURE 1 0 above, 
evaluates each programming element and associated 



operand for the current state. Appropriate to the pro- 
gramming elements and operand combinations en- 
countered, the execution model pushes onto an execu- 
tion stack 1108 data and function code to be executed 
according to the programming elements. A byte code 
interpreter 1110 takes the entries from the execution 
stack and processes the programming elements. It will 
be appreciated that changing the state table 1106 ad- 
vantageously controls application behavior without hav- 
ing to change the state change driver 11 02, the execu- 
tion model 1104, the execution stack 1108, or the byte 
code interpreter 1110. 

[0051 ] FIGURE 1 2 shows a computer system 1 200, 
which could be in the form of a media controller or a set- 
top box (STB) operable for using embodiments of the 
present invention. The computer system 1200 is oper- 
able for controlling a display 1202, such as a television, 
and an audio subsystem 1204, such as a stereo or a 
loudspeaker system. The computer system 1200 re- 
ceives input from a network 1206, such as a broadband 
data network. The computer system 1200 also receives 
user input from a wired or wireless user keypad 1208, 
which may be in the nature of a STB remote. 
[0052] The computer system 1200 receives input 
from the n etworkj 2 06_ via an _ input/qutp ut, contra I ler _ 
121 0, which directs signals to and from a video control- 
ler 1212, an audio controller 1214, and a central 
processing unit (CPU) 1216. In the case of a STB, the 
input/output controller 121 0 suitably is a multiplexer for 
routing video data blocks received from the network 
1206 to a video controller 1212 in the nature of a video 
decoder, audio data blocks to an audio controller 1214 
in the nature of an audio decoder, and for routing other 
data blocks to a CPU 1216 for processing. In turn, the 
CPU 1216 communicates through a system controller 
1218 with input and storage devices such as read only 
memory (ROM) 1220, system memory 1222, system 
storage 1224, and input device controller 1226. 
[0053] The computer system 1200 shown in FIGURE 
1 2 thus can receive state tables or state table files, pass 
them through the input/output controller 1210 to the 
CPU 1 2 1 6 where it will be processed through the system 
controller 1 21 8, suitably in response to user input gath- 
ered through the user keypad ,1 208 and the input device 
controller 1226. The state table can then be executed 
as previously described in connection with the foregoing 
examples, method flowcharts, and block diagrams. 
[0054] While the preferred embodiment of the inven- 
tion has been illustrated and described, as noted above, 
many changes can be made without departing from the 
scope of the invention. Accordingly, the scope of the in- 
vention is not limited by the disclosure of the preferred 
embodiment. Instead, the invention should be deter- 
mined entirely by reference to the Claims that follow. 
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Claims 



1 . A method for controlling computer system operation 
in response to state changes in the computer sys- 
tem, the method comprising: 

creating at least one state table having a first 
dimension and a second dimension, at least 
one programming element being listed along 
the first dimension and a plurality of states of 
the computer system being listed along the sec- 
ond dimension; 

storing an operand in a cell at each intersection 
of the first dimension and the second dimen- 
sion, the operand further being specified for the 
programming element at each state; and 
processing each programming element listed 
along the first dimension according to the op- 
erand listed for a current state for each state 
change of the computer system. 

• The method of claim 1 , further comprising placing 
a non-null operand onto an execution stack from 
which the non-nuli operand can be processed ac- 
cording to the programming element associated 
with the cell. " 
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3. 



The method of claim 2, further comprising retrieving 
the non-null operand from the execution stack and 
processing the operand according to the program- 
ming element associated with the cell. 

The method of claim 2 or 3, wherein the non-null 
operand includes a byte-code, the byte^ode repre- 
senting a predetermined action to a byte-code in- 
terpreter being executed by the programming ele- 
ment. 



30 



wherein the programming element includes a value 
setting function, wherein the operand includes a 
value to which a variable named in the program- 
ming element is set. 

The method of any one of the preceding claims 
wherein the operand includes a null operand such 
that no action is taken in processing the program- 
ming element. y 

The method of any one of the preceding claims 
wherein the programming element includes a code 
segment specifier and the operand includes a code 
segment to be executed. 

The method of any one of the preceding claims 
wherein the operands in the cells at each intersec- 
tion of the first dimension and the second dimension 
of the state table are of a fixed length. 

The method of any one of claims 1 to 11, wherein 
the operands in the cells at each intersection of the 
first dimension and the second dimension of the 
state table are of a variable length. 

^li^^L^J n ? f f* precedin 9 daims," 
reirnrre state laole Include a siaie table siruc- 

ture and a state table data file, such that the state 
table data file contains the operands stored in the 
cells at the intersections of the first and second di- 
mensions and the values of the operands can be 
changed by specifying a new state table data file to 
be used in the state table structure without having 
to load a new state table structure. 



5. The method of any one of the preceding claims 
wherein the programming element includes a func- 
tion call. 

6. The method of claim 5, wherein the function call in- 
cludes an automatic function call. 

7. The method of claim 6, wherein the operand in- 
cludes data used by the automatic function call 
such that when the automatic function call is initiat- 
ed by a state change of the computer system, the 
programming element performs its programmed 
function using the data specified as the operand. 

8. The method of claim 5, 6 or 7 wherein the operand 
includes a function specifier, the function specifier 
indicating what function should be executed by the ss 
function call programming element. 



15. The method of any one of the preceding claims 
wherein the state changes are triggered by one of 
preprogramming, user input, or an external event. 

« 16. The method of any one of the preceding claims 
wherein the execution of programming elements in 
response to state changes of the computer system 
is implemented according to a default transition or 
according to a specified transition. 
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9. 



The method of any one of the preceding claims, 



1 7. The method of claim 1 6, wherein the default transi- 
tion is an instantaneous transition. 

1 8. The method of claim 1 6, wherein the specified tran- 
sition to be applied in response to the state changes 
is specified by transition parameters included in the 
ceils at intersections of the first dimension and the 
second dimension of the state table. 

19. The method of claim 18, wherein the transition pa- 
rameters include at least one of a final state, a tran- 
sition type, and a transition duration. 
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20. A computer readable medium having stored there- 
on instructions which, when executed by a compu- 
ter, control operations of a computer in response to 
state changes, in accordance with any one of claims 
1 to 19. 

21 . A computer having the instructions defined in claim 
20 loaded thereon. 

22. A data system for controlling operation of a compu- 
ter system in response to state changes in the com- 
puter system, the system comprising: 

at least one state table having a first dimension 
and a second dimension, at least one program- 
ming element being listed along the first dimen- 
sion and a plurality of states of the computer 
system being listed along the second dimen- 
sion; 

an operand being stored in a cell at each inter- 
section of the first dimension and the second 
dimension, the operand being specified for the 
programming element at each state; and 
an operand processor processing each pro- 
gramming element listed along the first dimen- 
sion' according to'the operand listedln 'the ceil ~ 
fo r a curr e nt sta^e-for-eaeh-state-changer— 
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29. The system of claim 26, 27 or 28, wherein the op- 
erand includes a function specifier, the function 
specifier indicating what function should be execut- 
ed by the function call programming element. 

30. The system of any one of claims 22 to 29, wherein 
the programming element includes a value setting 
function, wherein the operand includes a value to 
which a variable named in the programming ele- 
ment is set. 

31 . The system of any one of claims 22 to 30, wherein 
the operand includes a null operand such that no 
action is taken in processing the programming ele- 
ment. 



32. The system of any one of claims 22 to 31 , wherein 
the programming element includes a code segment 
specifier, wherein the operand includes a code seg- 

20 rnent to be executed. 

33. The system of any one of claims 22 to 32, wherein 
the cells at each intersection of the first dimension 
and the second dimension are of a fixed length. 



25 



34. The system of any one of claims 22 to 32, wherein 
t he c ell s a t each in te r sect i o n of the fi r st dimension 



23. The system of claim 22, further comprising an exe- 
cution model for placing a non-null operand onto an 
execution stack from which the non-null operand 
can be processed according to the programming el- 
ement associated with the cell. 

24. The system of claim 23, further comprising a byte- 
code interpreter for retrieving the non-null operand 
from the execution stack and processing the oper- 
and according to the programming element associ- 
ated with the cell. 

25. The system of claim 22 or 23, wherein the non-null 
operand includes a byte-code, the byte-code repre- 
senting a predetermined action to the byte-code in- 
terpreter to be executed by the programming ele- 
ment. 

26. The system of any one of claims 22 to 25, wherein 
the programming element is a function call. 



and the second dimension are of a variable length. 

30 35. The system of any one of claims 22 to 34, wherein 
the state table includes a state table structure and 
a state table data file, such that the state table data 
file contains the operands stored in the cells at the 
intersections of the first and second dimensions and 

35 the values of the operands can be changed by spec- 
ifying a new state table data file to be used in the 
state table structure without having to load a new 
state table structure. 

40 36. The system of any one of claims 22 to 35, wherein 
the state changes are triggered by one of prepro- 
gramming, user input, or an external event. 

37. The system of any one of claims 22 to 36, wherein 
. 45 the execution of programming elements in re- 
sponse to state changes of the computer system is 
implemented according to a default transition or ac- 
cording to a specified transition. 



27. The system of claim 26, wherein the function call 
includes an automatic function call. 



50 38. The system of claim 37, wherein the default transi- 
tion is an instantaneous transition. 



28. The system of claim 27, wherein the operand in- 
cludes data used by the automatic function call, 
such that when the automatic function call is initiat- 
ed by a state change of the computer system, the 
programming element performs is programmed 
function using the data specified as the operand. 



39. The system of claim 37, wherein the specified tran- 
sition to be applied in response to the state changes 
is specified by transition parameters included in the 
cells at intersections of the first dimension and the 
second dimension of the state table. 
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40. The system of claim 39, wherein the transition pa- 
rameters include at least one of a final state, a tran- 
sition type, and a transition duration. 
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